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1  INTRODUCTION 

This  Quarterly  Technical  Report  is  the  current  edition  in  a 
series  of  reports  which  describe  the  work  being  performed  at  BBN 
in  fulfillment  of  several  ARPA  work  statements.  This  QTR  covers 
work  on  several  ARPA-sponsored  projects  including  (1)  development 
and  operation  of  the  SATNET  satellite  network;  (2)  development  of 
the  Pluribus  Satellite  IMP;  (3)  Internet  Operations,  Maintenance, 
and  Development;  and  (4)  development  of  the  Mobile  Access 
Terminal  Network.  This  work  is  described  in  this  single 
Quarterly  Technical  Report  with  the  permission  of  the  Defense 
Advanced  Research  Projects  Agency.  Some  of  this  work  is  a 
continuation  of  efforts  previously  reported  on  under  contracts 
DAHC15-69-C-0179,  F08606-73-C-0027 ,  F08606-75-C-0032 ,  MDA903-76- 
C-0214,  MDA903-76-C-0252,  N00039-79-C-03 86 ,  and  N00039-78-C-0405 . 


Report  No.  5286 


Bolt  Beranek  and  Newman  Inc. 


2  SATNET  DEVELOPMENT  AND  OPERATION 

As  part  of  our  participation  in  the  Atlantic  Packet 
Satellite  Experiment  (SATNET)  during  the  last  quarter  we 
conducted  a  Supreme  Headquarters  Allied  Powers  Europe  (SHAPE) 
Technical  Centre  demonstration,  and  performed  the  Satellite  IMP 
software  maintenance  operations  and  the  overall  SATNET  hardware 
maintenance  operations.  These  tasks  are  described  in  the 
following  sections.  Some  of  our  other  activities  are  described 
below. 


In  this  quarter,  the  BBN  gateway  between  SATNET  and  ARPANET 
was  decommissioned,  and  the  associated  circuit  between  BBN  in 
Cambridge,  Massachusetts,  and  the  Etam  Satellite  IMP  in  West 
Virginia  was  removed  from  service.  The  VDH  hardware  formerly 
attached  to  the  BBN  gateway  was  subsequently  shipped  to  the 
Center  for  Seismic  Studies  .  (CSS)  in  Arlington,  Virginia,  for 
installation  into  a  newly  commissioned  gateway  between  SATNET  and 
ARPANET.  After  many  frustrating  exchanges  with  the  agencies 
involved,  extending  over  many  days,  the  associated  circuit 
between  the  CSS  gateway  and  the  Etam  Satellite  IMP  was  made 
operational.  The  last  fixes  were  to  undo  a  data  inversion  on 
both  lines  of  the  circuit  and  to  change  an  AT&T  modem  from  being 
strapped  for  an  internal  clock  to  an  external  clock. 
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Having  two  gateways  between  SATNET  and  ARPANET,  namely  the 
CSS  gateway  and  the  DCEC  gateway,  improves  the  quality  of  service 
between  those  two  networks  and  ultimately  between  Europe  and 
CONUS.  On  those  occasions  when  GGP  packets  exchanged  between 
adjacent  gateways  for  the  determination  of  neighbor  status  are 
lost  in  SATNET,  we  observe  one  gateway  declaring  pathways  to  the 
European  gateways  down,  while  the  other  gateway  is  declaring  them 
up.  The  existence  of  an  alternate  gateway  path  between  two 
transport  networks  is  unique  in  the  internet  system. 

Because  of  the  decommissioning  of  the  BBN  gateway,  a  "stub” 
gateway  (connected  to  ARPANET  only)  was  installed  at  the  IP 
address  10.3.0.40  to  redirect  traffic  being  sent  to  the  BBN 
Gateway.  However,  because  the  ARPANET  IMP  BBN40  was  relocated 
several  weeks  before  the  circuit  between  the  BBN  gateway  and  the 
Etam  Satellite  IMP  had  been  decommissioned,  the  stub  gateway  was 
installed  earlier  to  permit  the  BBN  gateway  to  be  relocated 
temporarily  at  the  IP  address  10.5.0.82. 

We  transferred  SATNET  monitoring  from  the  Information 
Sciences  Institute  (ISI)  ARPANET  host  USC-ISID  T0PS-20  computer 
to  the  BBN-NET  host  BBN-IN0C  C/70  UNIX  computer.  The  programs 
RECORDER  and  MONITOR  have  subsequently  been  removed  from  among 
the  jobs  with  automatic  startup  on  USC-ISID.  SATNET  monitoring 
is  now  being  performed  by  the  NU  monitoring  system,  which  is  also 
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used  for  monitoring  the  ARPANET,  the  WIDEBAND  satellite  net, 
gateways,  and  the  BBN-NET,  among  others.  Commonality  of  network 
monitoring  programs  facilitates  software  maintenance. 

2.1  SHAPE  Technical  Centre  Demonstrations 

We  participated  in  a  demonstration  of  SATNET  monitoring  at  a 
symposium  held  in  the  SHAPE  Technical  Centre  (STC)  in  The  Hague, 
Netherlands,  on  9-10  November  1982.  Demonstrations  also  included 
gateway  monitoring,  X.25  and  IP  network  coupling,  and  C2 
graphics,  in  order  to  provide  exposure  of  the  internetwork 
capabilities  to  a  wider  audience.  Although  the  preparations  were 
hectic,  accompanied  by  some  anxious  moments  in  between,  ^he 
demonstrations  proceeded  quite  smoothly.  Contributing  to  the 
problems  seen  was  that  long  distance  phone  calls  from  the  STC 
sometimes  required  half  an  hour  to  be  placed;  thus,  we  were 
unable  to  obtain  assistance  quickly  when  malfunctions  developed 
in  critical  elements. 

A  simplified  representation  of  the  network  configuration 
used  in  the  demonstrations  is  shown  below: 
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An  LSI-11/23 

host 

with  a  Royal  Signals 

and 

Radar 

Establishment 

( RSRE)  X.25 

line  unit  interface 

for 

connection  to 

the  computer 

network  at  RSRE  was  established  at 

the 

STC . 

The 

BBN-NET  host 

INOC  was 

used 

by  BBN  for  gateway  monitoring 

and  SATNET 

monitoring,  while 

the  ARPANET  host 

use- 

ISIB 

was  used 

by  ISI  for 

C2  graphics 

and 

briefing  aid 

demonstrations . 

Not  shown  are 

several  hosts 

and 

networks  used  by 

RSRE 

for 

demonstrating  access 

with  X.25  public 

data  networks. 

Between 

the 

Etam  Satellite 

IMP 

and 

the  STC  host,  the 

pathways  used  are  non-redundant ;  a  failure  of  any  one  component, 
whether  it  be  a  circuit,  modem,  processor,  or  satellite  channel, 
would  disrupt  communications.  However,  the  dual  gateways  BBN  and 
DCEC  were  of  considerable  help  in  keeping  the  TCP  links  stable; 
namely,  on  those  occasions  when  GGP  packets  exchanged  between 
adjacent  gateways  for  the  determination  of  neighbor  status  are 
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lost  in  SATNET,  one  gateway  would  declare  pathways  to  the 
European  gateways  down,  while  the  other  gateway  would  declare 
them  up. 

Temporarily  detoured  from  its  final  destination  at  Patch 
Barracks  in  West  Germany,  the  LSI-11/23  host  at  the  STC  included 
the  following  equipment: 

DEC  LSI-11/23  computer  system 
20  megabyte  Winchester  disk  drive 

8-inch  double-density  dual-sided  floppy  disk  drive 
4  DEC  DLV-11J  4-port  asynchronous  interfaces 
Black  Box  RS-422/ RS-232  converters 
TI  Omni  800/model  840  hard-copy  terminal 

Terminals  on  the  STC  premises  made  available  for  the 

demonstrations  were  one  each  of  the  following: 

TERMINAL  SLAVE  MONITOR  (TAPPED  OFF  THE  VIDEO  OUTPUT) 

DEC  VT100  5-foot  projection  color  TV 

DEC  VT132  21-inch  color  TV 

Newbury  VDU  25-inch  B&W  TV 

Tektronics  4014  none 

Column  1  of  the  5-foot  projection  color  TV  monitor  was  for  the 
most  part  unreadable,  due  to  a  malfunction  of  the  retrace 
mechanism.  Because  the  red  gun  and  the  blue  gun  of  this  monitor 
were  slightly  out  of  focus,  we  turned  these  guns  off  to  leave  a 
green  image  on  the  screen.  Similarly,  we  left  only  the  yellow 
gun  powered  on  the  21-inch  color  monitor  to  provide  a  yellow 
image  on  the  screen.  This  monitor,  which  was  suspended  from  the 
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wall  above  head  level,  was  dedicated  to  running  the  SATNET  status 
program  LTBOX,  while  the  other  two  monitors  were  shared.  After 
several  telephone  calls  to  Linkabit  personnel,  who  created  the 
LSI-11/23  host  software,  the  correct  configuration  of  the  host 
software  for  operation  with  four  terminals  in  the  STC  environment 
was  achieved. 

Prior  to  the  demonstrations,  host  INOC  on  the  BBN-NET  wa- 
converted  from  NCP  service  to  TCP  service,  concomitant  with  tht 
eventual  conversion  of  ARPANET  to  TCP.  Because  the  conversio 
was  accompanied  by  some  difficulties,  not  until  the  day  before 
the  demonstrations  had  TCP  access  to  INOC  been  made  to  work 
satisfactorily . 

For  the  duration  of  the  demonstrations,  the  STC  host  had 
sole  use  of  a  port  on  the  RSRE  network.  When  the  modems  on  the 
circuit  between  STC  and  RSRE  began  losing  carrier 
synchronization,  RSRE  personnel  switched  the  X.25  line  unit  at 
STC  to  its  backup  modules,  which  seemed  initially  to  alleviate 
the  situation  but  in  actuality  did  not  effect  a  cure. 
Subsequently,  following  suggestions  given  by  the  British  Telecom, 
RSRE  had  the  modems  at  both  ends  of  the  circuit  switched  from 
9600  baud  to  7200  baud  to  effect  a  cure. 

We  observed  on  several  occasions  during  the  week  of  the 
demonstrations  a  fundamental  problem  in  SATNET,  such  that  user 
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communications  between  SATNET  and  ARPANET  were  blocked,  while 
monitoring  reports  were  being  processed  normally.  Since 
monitoring  reports  from  SATNET  were  continuing  to  be  received  at 
INOC,  the  Network  Operations  Center  had  no  knowledge  that 
communication  through  SATNET  was  broken.  Later,  the  cause  was 
traced  to  a  bug  in  the  SATNET  Satellite  IMP  which  consumed  all 
the  user  buffers.  To  unblock  SATNET,  we  had  to  have  the  Etam 
Satellite  IMP  reloaded  on  several  occasions.  Subsequently,  the 
automatic  stream  facility  for  gateway  traffic  was  disabled  to 
prevent  recurrence  of  the  situation. 

In  the  process  of  working  with  the  system,  we  observed 
numerous  system  restarts  of  the  STC  host,  presumably  due  to 
interruptions  on  the  220-volt  primary  power.  Other  than 
interrupting  our  TCP  connections,  this  did  not  adversely  affect 
us,  because  the  system  was  set  to  restore  the  host  software 
automatically . 

We  also  observed  that  whenever  a  TCP  connection  to  the  EDN- 
UNIX  was  established,  the  RSRE  gateway  software  would  run  out  of 
buffers  and  cease  working.  This  happened  twice  during  the  days 
of  the  demonstrations;  thereafter,  reading  mail  from  EDN-UNIX  was 
disallowed . 

Despite  all  the  problems  mentioned  above,  the  demonstrations 
went  remarkably  well;  we  were  able  to  successfully  demonstrate 
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reliable  internetwork  communications  to  symposium  participants  on 
four  separate  occasions. 


2.2  Software  Maintenance  Operations 

During  this  quarter,  Satellite  IMP  versions  3.5:4  for 
Honeywell  316s  and  4.5:4  for  BBN  C/30s  were  released.  Among  the 
changes,  we  added  commands  to  cause  in  all  sites  either  a 
synchronous  restart  of  the  Satellite  IMP  program  or  a  synchronous 
jump  to  the  Loader/Dumper  program;  we  fixed  a  stream  scheduling 
bug;  and  we  incorporated  patches  developed  since  the  last 
software  release. 

The  major  change,  however,  is  that  the  source  code 
supporting  the  ARPANET  direct  connection  facility  via  SATNET 
(ARPANET  line  #77)  was  removed,  and  the  code  space  was  converted 
to  buffer  space,  thereby  increasing  the  buffer  space  by  about 
30%.  We  also  implemented  the  averaging  of  the  Testing  and 
Monitoring  (T&M)  data  generated  by  the  second  generation  PSP 
terminal.  Concurrently  the  NU  monitoring  program  was  changed  to 
display  the  averaged  T&M  data. 

Work  on  incorporating  the  Native  Mode  Firmware  System  ( NMFS) 
in  Satellite  IMPs  continued  (in  NMFS,  the  emulated  machine  is 
altered  to  create  one  more  suited  to  communications  applications, 
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having  greater  throughput  capacity  nd  reduced  latency). 

2.3  Hardware  Maintenance  Operations 

During  the  quarter  several  hardware  problems  appeared  which 
we  helped  diagnose  and,  when  they  were  related  to  the  Satellite 
IMPs,  fixed. 

Because  of  a  slow  diminution  in  Goonhilly's  transmit  power, 
eventually  causing  serious  SATNET  channel  degradation,  COMSAT  had 
Goonhilly  site  personnel  insert  an  extra  amplifier  into  the 
transmit  side  of  the  PSP  terminal  to  bring  the  transmit  power  up 
to  acceptable  levels.  (An  extra  amplifier  was  previously 
installed  in  the  Tanum  PSP  terminal.) 

When  the  Etam  backup  PSP  terminal  channel  unit  failed, 
satellite  channel  time  was  allocated  to  COMSAT  for  checking  the 
unit.  After  it  was  determined  that  the  unit  could  not  be 
repaired  using  site  personnel  only,  COMSAT  personnel  traveled  to 
Etam  with  replacement  parts.  To  restore  service  when  on  another 
occasion  a  PSP  terminal  unit  at  Etam  had  malfunctioned,  it  was 
necessary  to  reseat  the  Linkabit  receive  module  many  times  (this 
module  would  not  respond  to  the  system  reset  signal  or  to  cycling 
the  power  off  and  on). 
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Because  all  the  PSP  terminals  in  the  field  have  a  new  CMM 
interface  employing  RS-232  protocol,  the  Satellite  IMP  cannot 
issue  commands  to  any  of  the  PSP  terminals,  either  to  reset  them 
or  to  cause  them  to  change  into  different  states  (C/30  hardware 
is  needed).  One  ramification  of  this  is  that  the  Satellite 
Loader/Dumper  program,  which  does  not  tolerate  T&M  on,  no  longer 
is  able  to  turn  T&M  off.  On  occasions,  we  have  had  to  call  sites 
to  turn  T&M  off  manually,  resulting  in  longer  delays  in  the 
reloading  of  sites.  We  have  been  trying  to  fix  the  Satellite 
Loader/Dumper  program  so  that  T&M  on  is  not  detrimental  to 
channel  operations;  however,  this  is  currently  working  for  C/30s 
but  not  for  Honeywell  316s. 

Large  channel  frequency  drifts  occurred  at  Goonhilly, 
requiring  site  personnel  to  replace  the  up-converter;  later,  the 
new  unit  showed  abnormally  large  drifts  as  well.  After  COMSAT 
adjusted  the  uplink  frequency  at  Raisting,  we  observed  an  80% 
reduction  in  packet  lossage  on  the  channel.  A  problem  in  loading 
the  Clarksburg  C/30  Satellite  IMP  from  cassette  tape  was  traced 
to  a  malfunctioning  memory  chip  in  the  microcode  memory.  Severe 
winter  storms  at  Etam  and  at  Tanum  disrupted  service. 
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3  PLURIBUS  SATELLITE  IMP  DEVELOPMENT 

During  the  quarter,  activities  at  BBN  focused  on  Wideband 
Satellite  Network  operations,  PSAT  hardware  maintenance,  PSAT 
software  maintenance,  and  BSAT  software  development.  The  Network 
Operations  Center  at  BBN  assumed  increased  responsibility  for 
network  operations  using  the  NU  system  running  on  BBN-INOC  -for 


network 

monitoring 

and 

control . 

With  a  few  exceptions, 

the 

network 

ran 

fairly 

well 

during 

the  quarter.  BSAT  software 

development 

during 

the 

quarter 

concentrated  on  testing 

and 

measurement  of  initial  BSAT  host  processes  and  the  Butterfly 
operating  system’s  process  scheduler. 

3.1  Network  Operations  and  Status 

A  meeting  was  held  at  Lincoln  Laboratory  between  Western 
Union,  Linkabit,  BBN,  and  Lincoln  on  November  12,  1982  to  resolve 
problems  that  had  been  encountered  with  the  remote  site 
monitoring  equipment  installed  in  the  earth  stations  by  Western 
Union.  Western  Union  and  Linkabit  reviewed  the  ESI-earth  station 
control  and  status  interface  specification.  Problems  at  specific 
sites  were  discussed  and  Western  Union  agreed  to  follow  up  on 
them.  The  relationship  between  the  Network  Operations  Center  at 
BBN  and  Western  Union’s  WESTAR  Satellite  Operations  Center  at 
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Glenwood,  NJ  was  worked  out.  Western  Union  will  inform  the  NOC 
of  any  alarm  conditions  in  the  network  that  are  reported  to  them. 
In  addition,  they  will  get  permission  from  the  NOC  before  they 
bring  any  of  the  sites  up  or  down. 

As  a  follow-up  on  the  channel  performance  measurements  made 
by  BBN  during  October,  Burst  Test  Modem  (BTM)  tests  conducted 
between  Lincoln  Laboratory,  ISI,  and  SRI  on  December  14  indicated 
that  there  had  been  a  severe  deterioration  in  the  quality  of  the 
satellite  channel.  All  sites  received  ISI  and  LL  with  bit  error 
rates  (BER)  at  3.0Mb/s  of  between  2*10**-2  and  9.2*10**-3.  SRI 
was  transmitting  at  a  slightly  higher  level  and  was  received 
better  at  all  of  the  sites.  Western  Union  determined  that  the 
other  users  in  the  Wideband  Network's  transponder  group  were 
transmitting  at  too  high  a  level  and  saturating  the  transponders 
power  amplifier,  producing  intermodulation  distortion  which 
showed  up  as  an  elevated  noise  floor  on  the  Wideband  Network's 
satellite  channel.  Western  Union  reduced  the  transmit  power 
level  of  the  other  users  and  the  BTM  tests  were  repeated.  The 
BERs  were  now  less  than  10**-3  except  at  ISI  which  was 
1.47*10**-3.  A  plan  is  being  worked  out  to  monitor  the  channel 
performance  on  a  regular  basis. 

Probe  Systems  made  RFI  (radio  frequency  interference) 
measurements  at  ISI  during  the  week  of  January  17.  Their 
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preliminary  findings  indicated  that  the  source  of  the  long¬ 
standing  RFI  problem  may  be  signals  from  radar  altimeters  of 
aircraft  approaching  the  L.A.  airport.  It  is  possible  that  these 
signals  are  being  picked  up  by  the  antenna  and  aliased  into  the 
earth  station  receiver's  frequency  band  by  a  nonlinearity  in  the 
downconverter ' s  mixer  circuits. 

During  the  quarter,  the  PSAT  paper  tape  readers  at  all  of 
the  sites  were  replaced  by  cassette  tape  readers.  Cassette  tapes 
with  both  a  copy  of  the  PSAT  operational  program  and  the  cross- 
net  loader  program  were  distributed  to  all  sites. 

A  PSAT  was  installed  at  RADC,  Griffiss  Air  Force  Base,  Rome, 
NY,  on  December  20,  1982  and  a  Lincoln  Laboratory  Packet-to- 
Circuit  Interface  (PCI)  host  was  installed  there  on  January  17. 
On  January  24,  the  PSAT  was  connected  to  the  ARPANET  as  Host  1  on 
IMP  18.  The  earth  station  had  been  installed  by  Western  Union 
during  August  1982.  At  this  point,  however,  the  site  is  not  able 
to  operate  on  the  channel  as  the  Linkabit  Earth  Station  Interface 
(ESI)  has  not  yet  been  installed. 


« 


3.2  Network  Hardware  Maintenance 

Due  to  problems  in  the  EDN-net,  the  DCEC  PSAT  was  isolated 
from  the  ARPANET  and  could  not  be  reloaded  during  the  period 
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November  1-15.  The  PSAT  had  been  connected  to  an  IMP  on  the 
EDN-net  and  lack  of  an  IMP  test  program  on  that  network  hampered 
progress  in  tracking  down  the  source  of  the  problem.  The  only 
ARPANET  IMP  host  port  that  the  PSAT  could  be  temporarily 
connected  to  was  the  one  used  by  EDN-gateway,  which  was  needed 
for  the  Internet  demonstration  at  STC  in  the  Netherlands  during 
the  week  of  November  8.  Following  the  demonstration  at  STC,  the 
PSAT  was  connected  directly  to  EDN-gateway 1 s  host  port  on  ARPANET 
IMP  20  and  a  test  of  the  IMP’S  host  port  was  successfully  run  by 
the  NOC  at  BBN.  In  the  shuffling  of  the  cables,  the  PSAT’s 
isolation  problem  on  EDN-net  disappeared. 

On  January  4,  an  attempt  to  loop  DCEC  off  of  the  channel 
uncovered  another  break  in  the  EDN-net  which  again  isolated  the 
PSAT  from  the  ARPANET.  It  continued  to  be  monitored  and 
controlled  via  the  satellite  channel  from  other  wideband  sites. 
However,  once  looped  off  the  channel,  it  had  to  be  unlooped  from 
the  PSAT  console.  Toward  the  end  of  January,  the  PSAT  was 
permanently  removed  from  the  EDN-net  and  connected  directly  to 
the  ARPANET  as  Host  5  on  IMP  20. 

The  DCEC  PSAT  experienced  some  hardware  problems  on  January 
24.  BBN  field  service  replaced  a  bus  control  unit  on  the  lower 
common  memory  bus  and  a  power  supply  on  the  P22  processor  bus. 
It  was  finally  brought  up  again  on  January  28. 
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The  ISI  PSAT  experienced  some  intermittent  hardware  problems 
during  November  and  December.  Two  of  the  PSAT's  six  processors 
would  halt  and  require  manual  intervention  to  get  them  restarted. 
The  source  of  the  problem  was  difficult  to  track  down  due  to  its 
intermittent  nature.  A  bus  control  unit  and  several  of  the  bus 
couplers  in  the  system  were  replaced.  Finally  on  December  30, 
1982  a  BCP  (bus  coupler,  processor)  was  replaced  on  the  P20 
processor  bus  and  the  PSAT  has  not  had  the  problem  since  then. 

Throughout  the  quarter,  the  ESI  at  ISI  would  repeatedly  get 
itself  into  a  "locked-up"  state  and  not  respond  to  PSAT  RESET 
pulses.  At  times,  it  could  be  cleared  from  this  state  by  power 
cycling  the  modem  or  the  ESI  control  processor.  On  other 
occasions,  this  did  not  work,  and  the  site  would  be  left  in  PSAT 
internal  loopback.  Eventually,  the  ESI  would  get  itself  out  of 
this  "lock-up"  state  and  begin  functioning  correctly.  Spurious 
signals  received  from  the  channel  or  the  earth  station  by  the  ESI 
may  be  the  source  of  this  "lock-up"  problem.  Linkabit  is 
continuing  to  work  on  this  matter. 

The  ESI-earth  station  control  cable  at  ISI  had  been 
disconnected  since  August  27.  At  that  time,  it  was  found  to  be 
holding  the  earth  station  in  RF  loopback.  It  was  reconnected  on 
December  23  and  the  earth  station  did  not  automatically  switch 
into  RF  loopback.  However,  the  PSAT  found  the  RF-loopback  and 
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test-translator-failure  status  bits  to  be  erroneously  set.  On 
December  28,  an  attempt  was  made  to  manually  switch  the  earth 
station  into  RF  loopback  and  it  was  found  not  to  switch.  The 
ESI-earth  station  control  cable  was  disconnected  and  the  earth 
station  could  then  be  manually  switched  to  RF  loopback.  These 
problems  have  been  referred  to  Western  Union  and  Linkabit. 

The  Lincoln  PSAT  was  isolated  from  the  ARPANET  on  two 
occasions  during  January  due  to  problems  with  the  port  expander. 
At  the  end  of  that  month,  the  PSAT  was  temporarily  left  with  a 
direct  connection  to  IMP  10.  The  severe  snowstorm  in  Boston  on 
January  15  left  quite  a  bit  of  snow  in  the  satellite  antenna. 
The  dish  has  heating  elements  on  its  bottom  panels,  but  this 
storm  deposited  snow  and  ice  across  the  entire  dish.  A  -3db 
attenuation  in  signal  level  on  transmit  and  receive  caused  the 
site  to  repeatedly  fail  ranging,  and  it  was  left  in  loopback 
until  January  23 »  when  the  snow  had  melted  sufficiently  for  the 
site  to  hear  itself  again.  On  January  17 >  the  PSAT  was  found  to 
be  running  with  only  four  processors.  A  bad  power  supply  on  the 
P20  bus  was  found  and  replaced  by  BBN  field  service  on  January 
18. 

The  125  watt  high  power  amplifier  (HPA)  in  the  SRI  earth 
station  had  burned  out  on  January  12  and  was  replaced  with  the  75 
watt  spare  unit  on  January  15.  On  January  17 »  the  earth  station 
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was  found  to  be  not  transmitting.  Western  Union  found  that  the 
spare  75  watt  unit  had  burned  out  as  well.  An  overtemperature 
problem  in  the  earth  station  shelter  was  found  and  corrected  by 
Western  Union.  A  second  75  watt  HPA  was  then  installed  and  the 
site  was  brought  up  on  the  satellite  channel  on  January  20. 


3.3  Network  Monitoring  and  Control  from  BBN-INOC 

Software  was  added  to  the  Satellite  NU  system  to  allow 
operators  to  control  the  Wideband  Network  from  BBN-INOC.  In 
particular  commands  were  added  to  loop,  unloop,  and  reinitialize 
a  PSAT.  A  rudimentary  DDT  debugger  command  using  the  EXPAK 
protocol  was  developed  to  aid  programmers  in  debugging  network 
problems  from  BBN-INOC.  A  full  symbolic  DDT  debugger  exists  on 
BBN-TENEX.  Pending  the  development  of  NU  routines  to  handle  the 
Internet  Packet  Core  Protocol,  PSAT  cross-network  loading  is 
still  done  from  BBN-TENEX. 

An  account  was  set  up  on  BBN-INOC  to  allow  Wideband  Network 
users  to  get  network  status  information  and  monitor  their 
experiments . 
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3.4  PSAT  Software  Maintenance 

A  bug  was  found  in  the  PSAT's  message  copying  software. 
When  messages  were  addressed  to  two  different  hosts  on  a  PSAT, 
one  of  the  hosts  received  about  20?  of  the  packets  in  error.  BBN 
is  working  on  this  problem. 

When  the  PSAT  site  tables  were  enlarged  to  handle  the 
additional  six  sites  being  added  to  the  network,  the  FPODA 
control  subframe  grew  to  nine  slots.  This  reduced  the  channel 
bandwidth  available  for  datagram  and  stream  traffic.  BBN  patched 
the  software  to  eliminate  FPODA  control  subframe  slots  for  sites 
that  were  not  yet  on-line,  thus  increasing  the  amount  of  frame 
time  available  for  data. 


3.5  BSAT  Development 

BSAT  development  during  the  quarter  was  concentrated  in  two 
areas,  the  writing  of  new  software  and  the  measurement  of 
Butterfly  hardware  and  Chrysalis  operating  system  performance. 

On  November  2,  1982  the  BSAT  system  successfully  sent 
messages  from  the  Message  Generator  to  the  Echo  Host  and  then  to 
the  Message  Sink.  All  of  these  processes  were  running  within  one 
processor  node  without  using  the  Chrysalis  priority  scheduler. 
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Performance  severely  deteriorated  when  these  processes  were  run 
under  the  priority  scheduler. 

The  BSAT  development  team  began  working  with  the  Voice 
Funnel  project  to  test  the  Chrysalis  scheduler.  As  problems  with 
the  original  scheduler  were  uncovered,  a  new  process  scheduling 
algorithm  was  devised.  The  new  scheduler  appears  to  work  much 
better  and  was  undergoing  final  testing  at  the  end  of  the 
quarter,  prior  to  being  put  into  Butterfly  microcode  read  only 
memory  (ROM). 

A  number  of  sections  of  the  Channel  Protocol  Module  (CPM) 
have  now  been  written.  These  include  the  CPM  datagram 
aggregation  and  scheduling,  initial  acquisition,  ranging,  and  the 
basic  frame  oriented  internal  sequencing  of  events.  Code  exists 
to  make  datagram  reservations,  send  them,  and  time  them  out. 

3.6  PSAT  Usage  of  Memory  Buffers 

During  December,  BBN  conducted  a  study  of  the  PSAT's  usage 
of  memory  buffers.  This  study  was  carried  out  in  preparation  for 
the  design  of  a  new  PSAT  buffer  management  system.  In  its 
current  configuration  the  PSAT  has  240  buffers,  each  of  which  is 
400  bytes  in  length. 
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3.6.1  Analysis  of  PSAT  Buffer  Usage 


PSAT  buffer  usage  has  been  broken  down  into  several 
categories.  The  first  division  is  between  the  Host  Protocol 
Module  (HPM)  and  the  Channel  Protocol  Module  (CPM).  Buffer  usage 
within  these  two  software  modules  is  further  broken  down  between 
the  uplink  and  downlink  paths. 

HPM  uplink: 

1.  16  buffers  are  permanently  assigned  to  the  device  input 
queue  for  each  host  that  is  up. 

2.  Buffers  destined  for  the  CPM  or  for  local  hosts  are  kept 
until  delivered  by  the  HPM  uplink  software. 

3.  One  buffer  per  host  that  is  declared  up  is  used  briefly  once 
per  second  for  host  status  messages. 


CPM  uplink: 

1.  If  the  PSAT  is  leader,  it  will  use  two  buffers  at  all  times 
for  leader  packets.  Leader  packets  are  scheduled  one  frame 
in  advance. 

2.  Each  channel  stream  will  use  two  buffers  at  all  times  for 
stream  control  packets.  Buffers  will  also  be  used  for  data 
packets.  These  buffers  will  be  used  for  approximately  two 
frames. 

3.  Any  setup  that  is  sent  will  use  two  buffers  for  two  frames 
on  the  uplink.  This  occurrence  should  be  relatively 
infrequent . 

4.  In  addition  to  the  data  buffers,  a  datagram  burst  that  is 
sent  will  use  one  buffer  for  the  control  packet  and  one 
buffer  for  the  fragmentation  and  reassembly  buffer.  These 
buffers  are  held  by  the  CPM  for  19  frames  (1/4  second) 
before  being  sent,  unless  the  reservation  is  lost.  The  19 
frames  include  17  frames  before  the  reservation  times  out 
and  two  frames  for  the  burst  to  be  scheduled  and  sent. 
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5.  Control  packet  traffic  in  the  minimum  control  subframe 
should  be  fairly  low  (usually  no  more  than  18  packets  per 
minute  per  PSAT).  Each  minimum  control  packet  will  use  one 
buffer  for  no  more  than  about  one  frame. 


CPM  downlink: 

1.  The  SATIN  strip  has  32  permanently  assigned  buffers. 

2.  All  control  packets  occupy  one  buffer.  They  are  held  long 
enough  to  process  the  information,  which  is  usually  less 
than  one  frame  time. 

3.  Data  packets  are  held  long  enough  to  determine  if  they  are 

destined  for  this  PSAT.  Data  packets  destined  for  this  PSAT 
are  immediately  passed  to  the  HPM.  The  number  of  data 
packets  received  from  the  channel  at  any  time  is 

indeterminate. 


HPM  downlink: 

1.  16  buffers  are  permanently  assigned  to  the  device  output 
queue  for  each  host  that  is  up. 

2.  All  buffers  containing  messages  destined  for  a  local  host 
are  held  long  enough  for  the  message  to  be  delivered  to  the 
host.  The  amount  of  time  this  takes  depends  on  the  speed  at 
which  the  host  can  take  messages. 

3.  one  buffer  is  used  briefly  once  per  minute  for  host  status 
messages . 


3.6.2  Model  of  Buffer  Usage 

A  mathematical  model  was  developed  to  describe  buffer  usage. 
Interface  buffers: 

CPM  downlink  —  32  buffers 

HPM  input  —  16*NH  buffers  (NH  =  no.  of  hosts) 

HPM  output  —  16*NH  buffers  (NH  =  no.  of  hosts) 
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Leader  traffic: 

Uplink  —  1 *LDR  buffers  (LDR  =  1  if  leader,  LDR  =  0  if 

not  leader) 

Downlink  —  1  buffer 


Stream  traffic  (per  stream  per  frame,  NS  =  no.  of  stream  bursts 
transmitted  per  frame): 

Uplink  —  2  buffers  for  control  packets 

2*NSD  buffers  for  data  packets 
(NSD  =  no.  of  buffers  of  data  in  stream  burst) 
Downlink  —  1  buffer  for  control  packet 

NSD  buffers  for  data  packet 


Datagram  traffic  (per  datagram  per  frame  on  average,  NS  =  no.  of 
datagram  bursts  transmitted  per  frame): 

Uplink  —  19  buffers  for  control  packets 

19  buffers  for  fragmentation 
19*NDD  buffers  for  data  packets 
( NDD  =  no.  of  buffers  of  data  in  datagram  burst) 
Downlink  —  1  buffer  for  control  packet 

NDD  buffers  for  data  packets 


The  following  equation  can  be  used  to  approximate  steady- 
state  buffer  use: 

BUFFERS_USED  =  32  +  32#NH  +  2#LDR  +  1  +  /«  Maintenance  */ 

NS  [  2( 1 +NSD )  +  (1+NSD)  ]  +  /*  Stream  traffic  */ 

ND  [  1 9 ( 1 +1 +NDD )  +  (1+NDD)  ]  /*  Datagram  traffic  */ 

=  33  +  32*NH  +  2*LDR  +  NS [ 3*( 1  +  NSD)]  +  ND[39  +  20*NDD] 


The  cost  of  additional  traffic  is  as  follows: 

1  stream  burst/frame  costs  3( 1+NSD)  buffers  per  frame. 

1  datagram  burst/frame  costs  (39  +  20*NDD)  buffers  per  frame. 

The  following  assumptions  were  made  in  deriving  this  model: 

1.  All  traffic  is  generated  by  this  PSAT  —  no  other  traffic  on 
the  channel. 
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2.  Input  traffic  from  the  hosts  arrives  with  exactly  one  frame 
between  messages  and  is  also  processed  at  precise  intervals 
within  the  PSAT. 

3.  There  are  no  setups  occurring. 

4.  There  is  enough  traffic  being  generated  by  this  PSAT  to 
allow  ranging  and  reservation  data  to  be  piggybacked  on  data 
packets. 

5.  Buffers  are  assumed  to  be  taken  and  freed  on  frame 
boundaries. 


3.6.3  Model  Testing  and  Results 


The  model  was  tested  under  several  different  scenarios  at 
BBN  and  Lincoln  Laboratory.  The  BBN  backroom  PSAT  was  leader 
(LDRsI),  had  a  connection  to  the  ARPANET  up  and  no  other  hosts 
(NH=1).  The  Lincoln  PSAT  was  leader  (LDR=1),  had  a  connection  to 
the  ARPANET  up  and  two  additional  external  local  hosts  active 
( NH=3 )  . 


1.  BBN  backroom  PSAT,  No  streams  or  datagrams 

2.  LL  PSAT,  No  streams  or  datagrams 

3.  LL  PSAT,  1  stream  burst/frame  with  1  data  buffer 

4.  LL  PSAT,  1  stream  burst/frame  with  2  data  buffers 

5.  LL  PSAT,  1  datagram  burst/frame  with  1  data  buffer 

6.  LL  PSAT,  1  datagram  burst/frame  with  3  data  buffers 

7.  LL  PSAT,  1  stream  burst/frame  with  1  data  buffers 

1  datagram  burst/frame  with  1  data  buffer 

8.  LL  PSAT,  1  stream  burst/frame  with  2  data  buffers 

1  datagram  burst/frame  with  1  data  buffer 


The  results  are  tabulated  below: 
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Scenario 

Free  Buffers 
Predicted 

Free  Buffers 
Observed 

1 . 

172 

172-175 

2. 

109 

110-112 

3. 

104 

106-108 

4. 

100 

101-104 

5. 

50 

51-56 

6 . 

22 

30-00 

7. 

44 

44-54 

8. 

41 

38-49 

The  model  seems  to  track  the  number  of  buffers  fairly 
accurately,  but  has  a  tendency  to  slightly  overestimate  the 
number  of  buffers  used  in  some  of  the  scenarios. 

3.6.4  Conclusion 

It  is  interesting  to  note  that  in  a  normal  running  system, 
99-131  buffers  out  of  240  are  dedicated  to  device  interfaces. 
This  leaves  141-109  buffers  left  to  use  for  traffic  as  it  flows 
through  the  PSAT.  Increasing  the  number  of  buffers  in  the  PSAT 
would  increase  the  number  of  buffers  available  to  handle  traffic. 
For  example,  if  the  PSAT  had  440  buffers  instead  of  240,  the  PSAT 
would  easily  be  able  to  transmit  two  datagram  bursts  per  frame, 
which  together  contain  a  total  of  10  buffers  of  data.  While 
sustaining  that  level  of  traffic,  the  PSAT  would  still  have  over 
30  buffers  left  to  process  traffic  from  other  sites  and  absorb 
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any  traffic  fluctuations.  With  its  current  240  buffers,  the  PSAT 
is  barely  able  to  support  1  datagram  burst  containing  3  buffers 
of  data. 
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4  INTERNET  DEVELOPMENT 
4.1  Introduction 

The  major  activity  during  the  past  quarter  was  the  continued 
deployment  and  maintenance  of  the  Macro-11  gateway.  Other 
important  work  included  enhancing  NU  gateway  monitoring, 
demonstrating  Gateway  monitoring  at  the  SHAPE  Technical  Center, 
and  supporting  the  Packet  Radio  exercises. 


4.2  Gateway  Installations 

New  gateways  were  installed  at  several  sites.  The  most 
important  was  at  the  Center  for  Seismic  Studies  (CSS),  which 
became  the  second  ARPANET  -  SATNET  gateway. 

A  gateway  was  installed  to  support  the  Packet  Radio  exercise 
BRIM  FROST.  Other  new  gateways  were  installed  at  the  University 
of  Wisconsin,  Purdue  University,  and  SRI  International.  The 
current  list  of  operational  gateways  is  shown  in  the  following 
table. 
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Gateway 

Adjoining 

Networks 

BBN 

ARPANET 

BBN-NET 

BBN-PR 

BBN-NET 

- 

BBN-PR 

BRAGG 

ARPANET 

- 

BRAGG-PR 

BRIMF 

ARPANET 

_ 

DEMO-PR 

CSS 

ARPANET 

— 

SATNET 

CRONUS 

ARPANET 

- 

DOS-ETHERNET  -  FIBERNET 

DCEC 

ARPANET 

- 

SATNET  -  EDN 

NTARE 

SATNET 

- 

NTARE-TIU  -  NTARE-RING 

PURDUE 

ARPANET 

- 

PURDUE-NET 

SRI-C3P0 

ARPANET 

- 

SF-PR-2 

SRI-C3PR 

ARPANET 

- 

SF-PR-3 

SRI-R2D2 

ARPANET 

— 

SF-PR-1 

UCL 

SATNET 

— 

UCLNET  -  RSRE/NULL  -  UCL 

wise 

ARPANET 

- 

WISC-NET 

4.3  Gateway  Status  Processor 

We  now  have  running  in  the  Internet  Network  Operations 
Center  (INOC)  a  gateway  status  processor,  which  keeps  track  of 
which  gateways  are  up,  down,  or  not  reachable  and  which  gateway 
interfaces  are  up  or  down.  The  display  produced  by  the  gateway 
status  processor  makes  it  quite  easy  for  the  operations  center 
personnel  to  check  gateway  up-down  status.  An  example  of  the 
display  output  is  shown  in  the  following  figure: 
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Gateway  Status  Display  j 


Gateway 

Interface 

1 

Interface 

2 

Interface 

3 

Interface 

4 

“  11  11 

BBN 

Arpanet 

UP 

BBN-net 

UP 

1 

t 

If 

C3P0 

Arpanet 

UP 

SF-PR-2 

DN 

1 

1 

IE 

C3PR 

Arpanet 

NR 

C3-PR 

DN 

1 

1 

K 

CRONUS 

Arpanet 

UP 

BBN-TC 

UP 

Cronus 

UP 

1 

1 

i  * 

CSS 

Arpanet 

UP 

Satnet 

UP 

1 

1 

i  ? 

DCEC 

Arpanet 

UP 

Satnet 

UP 

EDN 

UP 

1 

1 

i  -i 

MINET 

Arpanet 

UP 

Minet-Tst 

UP 

1 

1 

- 

i  / 

NTARE 

Satnet 

UP 

Ntare-Tiu 

UP 

Ntarenet 

UP 

1 

1 

u 

PURDUE 

Arpanet 

UP 

Purdue-CS 

UP 

1 

1 

I  • 

R2D2 

Arpanet 

DN 

SF-PR-1 

DN 

1 

1 

1 

UCL 

Satnet 

UP 

Rsre-Null 

UP 

Uclnet 

UP 

1 

1 

UCL-TAC 

UP 

1  1 

wise 

Arpanet 

Wisconsin 

UP 

1 

1 

-  +  - 

1 

1 

-+  . 

Last  status  change:  Wed  Feb  23  14:22:53  1983 
Time  now:  Wed  Feb  23  15:14:58  1983 


The  status  processor  works  by  periodically  sending  out  ICMP  ] 

m 

Echoes  to  all  of  the  gateways.  The  response  received  from  the 
Echo  messages  (Echo  Reply,  Destination  Dead,  Destination 
Unreachable,  etc.)  is  used  to  update  a  status  file.  Changes  to 
the  status  file  are  then  output  to  the  status  display.  ] 


4.4  SHAPE  Technical  Center  Demonstration 

We  gave  a  successful  demonstration  of  Internet  Gateway 
monitoring  at  a  symposium  on  ADP  Interoperability  held  at  the 
SHAPE  Technical  Center  (STC)  in  the  Hague,  Netherlands.  The 
demonstration  consisted  of  a  talk  describing  how  the  DARPA 
Internet  functioned,  followed  by  an  on-line  demonstration  of  the 
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tools  used  to  monitor  and  control  the  Internet  gateways.  We  did 
this  by  running  programs  on  the  INOC  computer,  located  at  BBN. 
We  were  connected  to  INOC  by  running  Telnet  on  a  Fuzzball  at  STC, 
which  was  connected  with  a  7.2Kb  line  to  the  network  at  RSRE,  in 
Malvern,  UK.  This  was  connected  to  the  rest  of  the  Internet  with 
a  line  to  the  gateway  at  University  College  London. 


4.5  Packet  Radio  Exercise  Support 

At  the  LOGEX  Packet  Radio  exercise  we  noticed  that  the 
gateway  was  frequently  dropping  its  interface  to  the  Packet  Radio 
network.  We  traced  this  problem  to  the  Packet  Radio  network 
sometimes  being  much  slower  to  accept  packets  from  the  gateway 
than  the  ARPANET  was  at  sending  them  to  the  gateway.  This  caused 
the  gateways'  output  queue  to  the  Packet  Radio  network  to  be  full 
for  relatively  long  periods  of  time,  causing  the  gateway  to  drop 
packets  destined  for  the  Packet  Radio  network.  Enough  of  the 
packets  dropped  were  GGP  Interface  Probes,  which  are  sent  by  the 
gateway  to  determine  if  the  network  is  up  or  down,  to  force  the 
gateway  to  declare  the  network  down. 

This  sequence  of  events  was  causing  the  gateway  to  declare 
the  Packet  Radio  network  down  in  times  of  congestion,  further 
adding  to  the  congestion.  The  strategy  employed  by  the  gateway 
to  send  GGP  Interface  probes  was  clearly  not  optimum.  We  changed 
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the  gateway  software  to  send  the  GGP  Interface  probes  at  higher 
priority.  The  gateway  will  now  put  one  of  these  messages  on  the 
output  queue  even  though  it  is  full.  This  new  strategy  was 
successfully  tested  at  the  BRIM  FROST  Packet  Radio  exercise  held 
in  Alaska.  The  old  problem  did  not  reappear. 
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5  MOBILE  ACCESS  TERMINAL  NETWORK 

As  part  of  our  participation  in  the  development  of  the 
Mobile  Access  Terminal  (MAT)  and  the  MAT  Satellite  Network 
(MATNET)  we  provided  extensive  support  for  the  system  integration 
and  the  ongoing  large  scale  system  testing.  The  system 
integration  was  divided  into  two  major  parts.  First,  af-ter 
shipping  the  ruggedized  Satellite  IMPs  if 3  and  if 4  to  E-Systems, 
ECI  Division,  in  St.  Petersburg,  Florida,  we  traveled  to  ECI  to 
integrate  these  units  with  the  associated  ruggedized  Terminal 
Input  Units  (TlUs),  crypto  hardware,  Black  hardware,  and  radio 
equipment  to  form  MATs.  These  MATs  (one  at  a  time)  were  tested 
at  ECI  on  MATNET  formed  by  MATs  #1  and  if 2  located  within  the 
Advanced  Command  and  Control  Architectural  Testbed  (ACCAT)  at  the 
Naval  Ocean  Systems  Center  (NOSC)  in  San  Diego,  California. 
Second,  we  installed  MAT  if 3  on  the  carrier  USS  Carl  Vinson 
(CVN70)  while  it  was  docked  in  Portsmouth,  Virginia.  Meanwhile, 
we  were  involved  in  the  system  testing  during  and  after  the  above 
installations.  Because  of  the  sparsity  of  available  FLTSATCOM 
satellite  time,  productive  use  was  imperative,  requiring  careful 
preparations.  In  order  to  convey  the  effort  involved  in  these 
activities,  a  detailed  summary  of  the  associated  events  is  given 
below,  presented  as  a  log  of  events  for  systematization  of  the 
information. 


-32- 


Report  No.  5286 


Bolt  Beranek  and  Newman  Inc. 


MONDAY  1  NOVEMBER  -  THURSDAY  4  NOVEMBER 

This  time  was  spent  preparing  the  new  ruggedized  MATNET 
hardware  at  ECI  for  the  first  satellite  testing  session  on  5 
November.  We  installed  the  new  equipment  in  laboratory  racks 
provided  specifically  for  the  purpose  of  conducting  tests.  The 
rack  configuration  was: 

RACK  #1  —  2  C/30  Satellite  IMPs 

1  cassette  tape  reader 

2  cryptos 

1  ON-143 

RACK  #2  —  2  LSI-11  TIUs 

2  LSI-11  Black  processors 

1  cassette  tape  reader 

2  AN/WSC-3  radios 

The  TIUs,  crypto  hardware,  Black  hardware,  and  radio  equipment 
are  ECI*s  responsibility,  while  the  C/30s  are  BBN’s 
responsibility.  Note  that  ECI  had  only  enough  crypto  equipment 
on  hand  to  support  a  single  MATNET  site;  nevertheless,  the  sites 
are  identified  as: 


Shorel  —  NOSC 
Ship2  —  NOSC 
Ship3  —  ECI 
Ship4  —  ECI 


The  C/30s 

survived  the 

trip 

to  ECI 

with 

only 

minor 

mechanical  damage 

to 

one  of 

the 

chassis , 

which 

was 

later 

straightened  out 

by 

ECI 

mechanical 

se  rv ices . 

Diagnostics 

were 
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run  successfully  after  the  units  were  assembled,  and  subsequently 
the  MATNET  Satellite  IMP  code  was  left  running  for  a  number  of 
overnight  periods  in  an  internally  cross-patched  mode.  No 
ruggedized  C/30  hardware  problems  were  encountered  at  any  time. 

A  significant  amount  of  time  was  spent  bringing  the  first 
ruggedized  TIU  on-line.  Among  the  problems  that  had  to  be 
corrected  were  incorrect  1822  cabling,  improper  LSI-11  module 
configuration,  and  a  malfunctioning  CPU  card.  Since  ECI  had  only 
one  robustness  module  at  this  time,  only  one  TIU  could  be 
configured  for  checkout  of  all  the  C/30  host  interfaces.  The 
robustness  modules  designated  for  installation  in  the  second  and 
third  ruggedized  TIUs  were  still  located  in  the  two  Black 
processors  at  NOSC  and  did  not  arrive  at  ECI  until  after  the  last 
day  of  satellite  tests  in  November.  In  order  to  release  these 
robustness  modules,  ECI  programmed  and  tested  PROMs  containing 
new  Black  processor  code  not  requiring  the  presence  of  a 
robustness  module.  A  Black  processor  with  the  new  PROMs  was  used 
for  checkout  of  all  the  C/30  Red/Black  interfaces. 

We  brought  with  us  cassette  tapes  on  which  were  written 
Satellite  IMP  versions  6.2:1  and  6.2:2,  where  the  former  is  the 
field  release  used  for  the  shipboard  demonstrations  on  the  USS 
Fanning  last  summer,  and  the  latter  is  the  field  release 
supporting  a  four-site  network  and  implementing  error  protection 
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on  the  packet  length  parameter  for  packets  sent  over  the 
satellite  channel.  Because  the  new  version  initially  had  host 
interfacing  problems,  it  was  used  for  the  Red/Black  interface 
tests,  while  the  old  version  was  used  for  the  TIU  checkout. 
Later,  the  host  interfacing  problems  with  version  6.2:2  were 
corrected . 

FRIDAY  5  NOVEMBER 

Due  to  the  lack  of  a  functional  codec  in  the  Ship2  Black 
processor,  the  first  satellite  test  was  limited  to  two  sites.  A 
replacement  codec  had  been  shipped  quite  a  few  days  earlier  but 
had  not  arrived  in  the  proper  hands  at  NOSC.  Another  codec  was 
shipped  from  ECI  to  NOSC  along  with  the  new  robustness-module 
independent  PROMs  in  an  effort  to  have  an  operational  Ship2  site 
ready  for  Monday's  tests.  Consequently,  only  one  codec  was  left 
on  hand  at  ECI,  allowing  only  one  Black  processor  to  be  fully 
configured  at  ECI. 

A  two-site  network  was  brought  up  running  Satellite  IMP 
version  6.2:1,  but  not  until  after  sorting  through  a  number  of 
time-consuming  problems,  including  malfunctions  >ith  one  of  the 
AN/WSC-3  radios  at  NOSC  and  confusion  resulting  from  the 
modification  of  the  TOPS-20  MONITOR/ RECORDER/EXPAK/QUERY  programs 
to  handle  a  four-site  network.  Lack  of  a  telephone  in  the  ECI 
testing  area  as  well  as  the  physical  separation  of  the  various 
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MATNET  components  at  NOSC  made  test  coordination  difficult  (a 
telephone  was  later  provided  in  the  ECI  test  center).  The  two- 
site  network  ran  without  any  significant  problems;  neither  frame 
nor  reservation  synchronization  was  lost  at  the  ECI  site  during 
one  and  one  half  hours  of  continuous  operation.  Telnet 
connections  were  routinely  opened  from  the  TIU  at  the  ECI  site  ^o 
the  ACCAT  T0PS-20  . 

MONDAY  8  NOVEMBER 

By  the  start  of  the  satellite  tests,  the  Ship2  site  was 
still  without  a  working  codec;  hence,  MATNET  was  again  restricted 
to  two  sites.  Iii  order  to  test  a  TIU-to-TIU  connection  (as  might 
be  used  in  ship-to-ship  communications),  the  TIU  connected  to  the 
non-functioning  Ship2  site  was  temporarily  moved  to  the  Shorel 
site.  The  two-site  network  was  brought  up,  and  three 
simultaneous  Telnet  connections  were  made:  a  ship-to-ship 
connection  between  the  two  TIUs  (used  for  ECI/NOSC  coordination) 
and  two  ship-to-shore  connections  from  the  ECI  TIU  to  the  ACCAT 
T0PS-20  (used  for  display  at  ECI  of  the  MONITOR  program  and  for 
general  access  to  TOPS-20  functions). 

Frame  synchronization  was  repeatedly  lost  during  the  network 
operations  on  this  date.  Although  unauthorized  use  of  the 
satellite  channel  was  observed  with  a  spectrum  analyzer  at  ECI, 
the  channel  was  not  being  monitored  closely  enough  to  confirm  any 
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correlation  between  the  interference  and  the  loss  of  frame 
synchronization.  A  decision  was  made  to  maintain  a  closer  watch 
on  the  satellite  channel  in  the  upcoming  tests  in  order  to 
establish  any  such  correlation. 

Towards  the  end  of  the  day's  satellite  time,  the  network  was 
run  using  Satellite  IMP  version  6.2:2.  Although  this  version 
could  not  yet  run  with  TIU  hosts,  the  gateway  host  did  operate, 
and  proper  network  operation  over  the  satellite  channel  was 
confirmed . 

TUESDAY  9  NOVEMBER 

A  working  codec  finally  became  available  at  NOSC  for 
installation  in  the  Ship2  Black  processor.  Time  was  spent 
debugging  the  Satellite  IMP  version  6.2:2  host  interfacing 
problem . 

WEDNESDAY  10  NOVEMBER 

For  the  first  time,  all  three  sites  were  ready  to 
participate  in  the  network.  However,  at  the  start  of  the 
allocated  satellite  time,  the  ACCAT  T0PS-20  was  non-operational , 
and  computer  operators  were  not  immediately  available  to  restore 
the  machine.  Because  the  ACCAT  T0PS-20  functions  as  the  network 
monitoring/control  host,  its  use  is  indispensible  to  network 
testing  operations. 
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Although  the  new  Black  processor  PROMs  had  arrived  at  NOSC, 
they  could  not  be  installed  in  time  for  the  day's  satellite 
testing.  This  was  unfortunate,  since  the  Shorel  Black  processor 
halted  twice  during  the  testing  session,  and  the  PROMs  contained 
the  new  version  of  the  Black  processor  software  with  all  halts 
removed.  Because  the  Black  processors  are  in  a  room  remote  from 
the  rooms  containing  the  Red  subsystems,  the  cause  of  a  system 
crash  at  NOSC  is  not  obvious  when  due  to  a  Black  processor  halt, 
and  considerable  time  is  lost  with  site  recovery. 

On  this  day,  all  three  sites  were  brought  up  running 
Satellite  IMP  version  6.2:1.  Numerous  Telnet  connections  were 
opened  from  both  the  Ship2  site  and  the  Ship3  site,  including  a 
Ship2-to-Ship3  link. 

A  close  watch  of  the  satellite  channel  on  the  spectrum 
analyzer  at  ECI  revealed  frequent  interference  from  unauthorized 
u'-^-s,  often  coinciding  with  the  loss  of  MATNET  frame  and/or 
reservation  synchronization  but  sometimes  causing  no  loss  of 
synchronization  at  all. 

THURSDAY  11  NOVEMBER 

The  Satellite  IMP  version  6.2:2  TIU  host  interfacing  problem 
was  corrected,  and  a  list  of  the  required  patches  was  prepared. 
The  new  PROMs  were  installed  in  the  NOSC  Black  processors,  but 
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one  of  the  two  sets  sent  did  not  appear  to  operate  properly. 
This  problem  was  worked  on  during  the  day,  with  the  decision  made 
to  use  the  old  PROMs  during  the  next  satellite  tests  if  the 
problem  with  the  new  PROMs  could  not  be  resolved. 

FRIDAY  12  NOVEMBER 

On  this  day  MATNET  was  again  limited  to  two  operational 
sites  due  to  a  failure  of  the  codec-interface  board  in  the  Ship2 
Black  processor.  Since  the  problem  with  the  board  could  not  be 
resolved  over  the  telephone,  a  replacement  board  was  shipped  from 
ECI  to  NOSC. 

Correcting  a  problem  with  the  RF  subsystem  at  ECI  occupied 
the  initial  part  of  the  day's  satellite  time.  Satellite  time  was 
also  spent  isolating  the  source  of  the  previously  observed  large 
global  time  drifts  to'  the  Ship2  C/30  hardware  (this  was 
accomplished  by  running  the  network  with  different  combinations 
of  site  IDs  and  C/30  hardware).  Replacement  16-MHz  C/30  master 
crystals  were  then  shipped  from  BBN  to  NOSC  to  correct  the 
problem . 

An  unauthorized  user  was  observed  on  the  satellite  channel 
for  approximately  two  and  one  half  hours.  For  most  of  that 
interval,  the  user's  presence  did  not  appear  to  disturb  the 
network,  although  there  did  occur  a  relatively  short  period  of 
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repeated  synchronization  loss. 

Towards  the  end  of  the  satellite  time,  the  two-site  network 
was  run  using  Satellite  IMP  version  6.2:2  with  the  TIU  host 
patches  inserted.  TOPS-20  connections  were  made  from  the  ECI 
TIU,  verifying  the  host  interfacing  problem  had  indeed  been 
corrected.  Thereafter,  only  version  6.2:2  was  used. 

MONDAY  15  NOVEMBER 

By  the  start  of  the  satellite  tests,  the  replacement  codec- 
interface  board  had  been  received  at  NOSC  and  installed  in  the 
Ship2  Black  processor.  Although  all  three  sites  ran  channel 
tests  successfully  (Black  subsystem  only),  difficulties  were 
encountered  in  bringing  up  a  three-site  network  due  to  the  Ship2 
Satellite  IMP  not  being  able  to  achieve  frame  synchronization. 
Since  improper  crypto  keying  for  the  Ship2  site  was  suspected,  an 
authorized  crypto  person  was  called  in  to  re-key  the  crypto 
equipment.  When  this  failed  to  cure  the  problem,  a  number  of 
cable  swapping  operations  were  made,  revealing  the  problem  to  be 
in  the  Ship2  Black  processor.  After  the  problem  had  been 
isolated  to  this  level,  satellite  time  had  expired,  leaving 
further  investigations  to  be  done  off-line. 

The  problem  was  traced  to  the  new  codec-interface  board, 
which  had  just  been  installed.  The  new  board  is  not  identical  to 
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the  old  board,  since  the  new  board  has  the  quality  monitoring 
circuitry  integrated  onto  the  board,  requiring  some  Black 
processor  backplane  rewiring.  Because  the  Black  processors  at 
the  NOSC  sites  did  not  have  the  wiring  modifications,  every 
received  packet  had  been  flagged  as  a  contention  packet  by  the 
quality  monitoring  circuitry  and  was  deliberately  corrupted  so  as 
to  be  received  in  error  on  the  Red  side.  Hence,  the  Satellite 
IMP  could  not  receive  its  round-trip  timing  packets  and  thus 
could  not  achieve  frame  synchronization.  In  order  to  have  the 
Ship2  site  operational  during  the  next  testing  session,  a 
temporary  wiring  change  was  made  on  the  new  board,  which  was 
successfully  tested  by  looping  the  Satellite  IMP  through  the 
Black  processor. 


For  a  brief  time  during  the  day's  satellite  tests,  ECI  was 
reconfigured  as  the  Ship4  site,  and  the  four-site  network 
monitoring  software  was  run  on  the  T0PS-20  with  no  problems 
encountered . 

TUESDAY  16  NOVEMBER 


On  this  day  there  were  failures  in  four  distinct  parts  of 
the  system. 

First,  a  problem  in  the  operation  of  the  PLI  at  NOSC, 
indicated  by  a  failure  of  the  PLI  to  assert  its  IMP-READY  line, 
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did  not  allow  MATNET  monitoring  reports  to  reach  the  T0PS-20; 
hence,  we  were  without  network  monitoring.  After  several  hours, 
the  problem  was  corrected  by  reloading  the  PLI. 

Second,  the  Ship2  Black  processor  would  not  run  properly, 
which  was  eventually  traced  to  a  malfunction  in  the  MXV11 
multifunction  card.  Fortunately,  another  such  card  was  availa-ble 
at  NOSC.  After  many  strapping  changes  to  convert  to  MATNET 
operation,  the  new  card  was  installed,  and  the  site  became 
operational . 

Third,  before  the  Ship3  site  came  on  the  air,  a  routine 
Red/Black  interfacing  check  revealed  an  intermittent  problem  in 
the  crypto  equipment.  The  problem  at  times  would  disappear, 
although  never  for  long  enough  to  bring  the  site  onto  the 
network.  Since  the  NOSC  Satellite  IMPS  could  hear  round-trip 
timing  packets  from  the  ECI  site,  the  problem  was  believed  to  be 
in  the  ECI  crypto  receive  side.  After  various  crypto 
machinations,  the  crypto  at  ECI  began  to  operate  properly,  but 
this  was  after  the  allocated  satellite  time  had  expired. 

Fourth,  the  second  and  third  TIUs,  when  checked  out  at  ECI 
using  the  single  available  robustness  module,  would  not  work. 
Eventually  we  determined  that  new  metallic  labels  that  had 
recently  been  affixed  to  the  PROMs  on  the  robustness  module 
created  electrical  short  circuits  between  pins  on  adjacent 
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boards.  When  the  labels  were  replaced,  proper  operation  of  all 
Tills  was  achieved.  Yet  another  malfunctioning  LSI-11  CPU  card 
was  found  in  this  process. 

WEDNESDAY  17  NOVEMBER  -  THURSDAY  18  NOVEMBER 

This  time  was  spent  with  the  installation  and  checkout  of 
the  Ship3  MAT  hardware  in  the  new  shipboard  racks  to  be  installed 
on  the  USS  Carl  Vinson.  First,  wiring  errors  had  to  be  corrected 
on  the  tape  cassette  device  selector  switch  for  determining 
whether  the  TIU  or  the  C/30  is  to  be  loaded.  Once  configured, 
the  equipment  was  tested  in  the  racks  by  looping  the  Satellite 
IMP  through  the  Black  processor  and  by  separately  checking  all 
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degradation  on  long  lines.  With  the  arrival  of  a  robustness 
module,  a  second  TIU  was  configured. 

Out  of  a  total  of  38  hours  of  satellite  time  available  in 
November,  we  were  able  to  run  three  sites  simultaneously  for  no 
more  than  three  hours  due  to  the  difficulties  encountered. 
Despite  the  rather  disappointing  performance  from  an  operational 
point  of  view,  we  were  able  to  shake  down  much  of  the  system.  In 
addition,  from  these  tests  we  can  draw  the  following  conclusions. 
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1.  At  NOSC,  where  the  equipment  is  distributed  in  four  widely 
separated  rooms,  monitoring  the  satellite  channel  while 
participating  in  network  operations  was  difficult.  In 
contrast,  at  ECI,  where  the  equipment  setup  is  all  in  one 
room  only,  we  were  routinely  monitoring  the  channel  with  a 
spectrum  analyzer. 

2.  Lack  of  spares  at  the  sites  required  multiple  cross-country 
transits  of  equipment.  Despite  overnight  deliveries  by 
Federal  Express,  equipment  normally  would  not  be  available 
for  use  during  the  satellite  tests  the  following  day. 

3.  Non-standardization  of  hardware  hurt  us  on  several 
occasions . 

4.  Unauthorized  use  of  the  channel  was  seen  repeatedly, 
although  sometimes  it  did  not  adversely  affect  MATNET 
communications . 

5.  Shared  assets  at  NOSC  means  the  equipment  must  be 
reconfigured  before  each  test,  increasing  the  risk  that  the 
site  is  unprepared. 

6.  Without  a  definite  commitment  to  keep  all  MATNET  related 
tools  operational  on  a  24-hour  basis,  there  were  functional 
outages  when  the  ACCAT  T0PS-20  crashed  one  night  and  when 
the  ACCAT  PLI  crashed  another  night. 

7.  During  those  times  when  simulation  programs  were  running  on 
the  ACCAT  TOPS-20 ,  system  response  was  noticeably  poor. 

8.  Lack  of  terminals  proved  an  annoyance. 


THURSDAY  2  DECEMBER  -  WEDNESDAY  8  DECEMBER 


By  the  beginning  of  December,  after  the  Ship3  MAT  was  moved 
from  ECI  to  the  USS  Carl  Vinson,  we  traveled  to  the  ship  to 
integrate  and  test  this  unit  on  MATNET.  Although  only  a  small 
amount  of  FLTSATCOM  satellite  time  was  available  for  these 
purposes,  we  reached  a  milestone  when  four  sites  were 
successfully  able  to  communicate  with  each  other;  these  sites 
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were : 


Shorel  —  NOSC 

Ship2  —  NOSC 

Ship3  —  USS  Carl  Vinson 

Ship4  —  ECI 

However,  the  shipboard  installation  did  have  its  share  of 
problems.  A  crypto  malfunction  kept  the  site  off  the  net  .for 
several  days;  the  crypto  was  eventually  replaced.  Due  to  a  long 
delay  inserted  into  the  shipboard  transmissions,  the  beginning  of 
packet,  where  the  Unique  Word  is  inserted,  was  corrupted. 
Because  of  a  problem  with  the  ship’s  cabling,  the  pulse  blanker 
signal  appeared  to  always  be  asserted  (the  entire  packet 
blanked).  When  the  robustness  card  in  the  NOSC  TIU  was  removed, 
the  address  stored  in  DIP  switches  on  the  card  was  destroyed.  On 
the  ship,  telephones  and  a  spectrum  analyzer  were  inconvenient  to 
operations . 

For  these  tests,  ship's  personnel  were  able  to  free  up  for 
the  TIU  only  one  terminal,  an  HDS  Concept  100  CRT  terminal,  which 
has  the  peculiar  characteristic  of  generating  a  BREAK  signal 
whenever  a  user  types  too  fast.  The  TIU,  upon  receiving  a  BREAK 
signal,  would  infer  a  framing  error  and  would  immediately  jump 
into  ODT  (the  LSI-11  debugger  program),  thereby  halting  all 
operations.  Adding  to  the  difficulties,  the  cable  from  the  CRT 
terminal  was  too  short  and  was  prone  to  pulling  off  the  TIU 
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connector.  To  compound  this  problem,  cramped  quarters  made 
inspecting  cables  difficult. 

FRIDAY  17  DECEMBER  -  WEDNESDAY  22  DECEMBER 

In  the  second  half  of  December,  the  FLTSATCOM  satellite  time 
allocated  for  MATNET  testing  was  a  total  of  six  consecutive  days. 
In  contrast  with  November's  satellite  tests,  these  satellite 
tests  were  quite  successful;  below  is  a  summary. 

In  preparation,  Satellite  IMP  version  6.2:3  software  was 
assembled  and  written  on  tape  cassettes  for  checkout.  The  major 
change  in  this  version  is  that  each  site  receives  a  specific 
cassette  tape  requiring  no  patches  whatsoever;  in  site 
preparation,  the  tape  is  loaded,  after  which  the  site  immediately 
accesses  the  satellite  channel  with  the  correct  addresses  and 
host  configuration.  In  these  tests,  the  Satellite  IMPs  were 
modified  to  perform  channel  scheduling  factoring  in  priority 
only.  Previously,  channel  scheduling  was  based  on  priority 
combined  with  delay  class. 

There  was  hope  that  Ship3  would  participate,  but  that  never 
happened;  participation  would  have  required  the  USS  Carl  Vinson 
to  give  up  its  secure  voice  capability  during  the  brief  interval 
of  its  test,  a  sacrifice  which  the  ship  was  unwilling  to  do.  To 
participate,  the  ship  requires  crypto  equipment  designated  for 
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MATNET. 

Except  for  the  last  day,  the  three  land-based  sites  were  on 
the  air  virtually  problem  free  the  entire  time.  None  of  the 
numerous  hardware  problems  plaguing  the  November  tests  occurred; 
consequently,  the  seemingly  endless  shipping  of  hardware  between 
ECI  and  NOSC  was  avoided.  The  only  problem  encountered  was  that 
severe  storms  in  California  on  22  December  caused  a  primary  power 
outage  at  NOSC,  thereby  completely  eliminating  both  the 
capability  of  running  MATNET  monitoring  programs  and  the 
participation  by  the  Shorel  and  Ship2  sites. 

The  December  tests  were  run  primarily  by  NOSC  personnel  with 
large  amounts  of  our  time  writing  detailed  instructions  and 
talking  on  the  telephone  to  assist  them.  One  satisfying 
conclusion  of  these  tests  is  that  on-site  personnel  have 
developed  the  capability  to  conduct  tests  without  our  presence. 

These  tests  were  designed  to  obtain  some  preliminary 
delay/ throughput  information;  message  generators  were  enabled  in 
all  sites,  while  statistics  were  being  collected  in  the  ACCAT 
TOPS-20 .  The  message  traffic  for  these  tests  was  generated  with 
constant  interarrival  time  and  with  constant  length  --  short  (3 
interleaver  blocks),  long  (9  interleaver  blocks),  and  mixed 
short-long.  Afterwards,  test  data  were  mailed  to  BBN  for 
analysis  (unfortunately  we  cannot  view  the  monitoring  information 
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directly,  because  it  is  collected  in  a  Red  area). 

Early  reports  indicate  the  results  are  good.  Some 
unauthorized  channel  interference  has  been  seen  on  a  spectrum 
analyzer,  but  the  effect  appears  to  be  minimal.  Synchronization 
of  the  different  sites  appears  not  to  have  been  a  problem. 

WEDNESDAY  5  JANUARY  -  FRIDAY  14  JANUARY 

In  these  tests,  more  delay/throughput  information  was 
collected  for  message  traffic  generated  with  geometric 
distributions  of  interarrival  time.  Only  the  Shorel  and  Ship2 
sites  participated  on  the  net,  because  ECI  did  not  receive  the 
right  crypto  key  to  allow  access  by  the  Ship4  site. 

MONDAY  17  JANUARY  -  FRIDAY  21  JANUARY 

We  traveled  to  NOSC  specifically  to  peform  contention  tests 
on  the  network  during  this  time.  In  preparation,  Satellite  IMP 
version  6.2:4  software  was  assembled  and  written  on  tape 
cassettes  for  checkout.  The  major  change  in  this  version  is  that 
channel  scheduling  is  done  by  factoring  in  priority  only;  tests 
in  December  demonstrated  the  feasibility  of  this  change.  In  the 
following  tests  only  version  6.2:4  was  used. 

In  order  to  verify  that  the  test  procedure  was  correct,  the 
contention  tests  were  divided  into  three  separate  experiments, 
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two  of  which  were  designed  as  experimental  control. 

f 

In  Experiment  #1  (non-contention,  experimental  control),  the 
AN/WSC-3  transmitter  for  each  site  was  checked  for  nominal  power 
and  frequency  settings,  and  each  Black  processor’s  quality 
monitoring  threshold  was  set  to  its  maximum  value,  effectively 
disabling  the  quality  monitoring  circuitry.  After  the  usual 
Black-subsystem-only  satellite  channel  tests  were  performed  at 
each  site,  MATNET  was  brought  up  running  the  FPODA  satellite 
channel  scheduling  protocol.  In  order  to  generate  regular, 
recurring  traffic,  each  Satellite  IMP’S  channel  protocol  module 
was  patched  to  transmit  a  control  packet  in  every  PODA  frame, 
whether  or  not  there  were  any  reservations  or  acknowledgments  to 
be  sent.  Since  each  site  transmitted  its  control  packets  in  its 
designated  slot  in  the  control  subframe,  no  packet  contentions 
were  being  forced. 

When  MATNET  was  operated  in  the  above  mode  for  a  period  of 
one  hour,  there  was  no  loss  of  synchronization  by  either  site 
other  than  during  a  two  minute  interval  when  unauthorized  use  of 
the  satellite  channel  was  confirmed  via  a  spectrum  analyzer. 
T0PS-20  MONITOR  reports,  Satellite  IMP  statistics,  and  Black 
processor  statistics  all  verified  the  correctness  of  the  channel 
protocol  module  patches;  i.e.,  each  site  was  indeed  transmitting 
a  control  packet  in  every  PODA  frame. 
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Surprisingly ,  the  Black  processor  data  for  Experiment  #1 
show  that  7%  more  unique  words  were  detected  by  the  Ship2  site 
than  were  transmitted;  14,011  non-contention  packets  were 
transmitted  by  the  two  sites  combined,  compared  with  15,017 
unique  words  detected  by  Ship2.  However,  1,215  packets  of 
undecodable  size  were  recorded  by  the  Ship2  site,  which  is 
consistent  with  the  number  of  false  unique  words  detected.  The 
detection  of  unique  words  that  do  not  correspond  to  transmitted 
packets  is  undesirable  since  it  causes  the  Black  processor  to 
block  the  satellite  channel  for  an  interval  corresponding  to  the 
size  of  at  least  a  single-block  packet,  during  which  time  real 
packets  are  lost.  Sometimes  a  packet  length  value  larger  than  a 
single  block  passes  the  validity  test,  and  the  channel  is  blocked 
for  longer  intervals.  Note,  the  error  detecting  code  that  is 
used  for  the  packet  length  field  will  detect  all  1-bit  and  2-bit 
errors.  However,  in  the  case  of  random  data  being  received  in 
the  Black  processor,  the  probability  that  a  packet  length  value 
passes  the  validity  test  is  10/256. 

In  Experiment  #2  (contention),  the  experimental 
configuration  was  identical  to  Experiment  #1  with  the  exception 
that  both  Satellite  IMPs  were  patched  to  transmit  their  control 
packets  in  the  same  control  subframe  slot.  This  was  done  to 
force  constantly  recurring  collisions  of  control  packets  on  the 
satellite  channel.  In  order  to  remove  all  normal  traffic  from 
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the  channel,  tne  generation  of  MONITOR  reports  was  disabled  in 
both  sites  and  the  MATNET  gateway  was  halted. 


When  MATNET  was  operated  in  the  above  mode  for  a  period  of 
one  hour,  frame  synchronization  was  repeatedly  lost  by  both 
sites,  even  though  no  outside  interference  was  ever  observed  on 
the  satellite  channel.  The  Shorel  site  lost  frame 
synchronization  more  frequently,  at  intervals  varying  from  about 
30  seconds  to  about  4  minutes.  With  such  frequent  loss  of  frame 
synchronization,  the  network  is  totally  unusable. 


We  hypothesize  that  the  following  specific  sequence  of 
events  could  be  occurring,  causing  the  loss  of  frame 
synchronization : 


1.  Despite  contention  on  the  satellite  channel,  the  Black 
processor  acquires  the  unique  word  of  one  of  the  contention 
packets.  The  packet-length  value,  sometimes  incorrectly 
large,  passes  the  Black  processor  validity  test,  and  the 
packet  is  clocked  through  the  crypto  to  the  Satellite  IMP. 

2.  The  Satellite  IMP  microcode  in  examining  the  stream  of  data 
from  the  crypto  finds  a  SYN  character  followed  by  a 
legitimate  packet  length  parameter  and  4-bit  parity 
combination.  Occasionally  packet  length  values  very  much 
larger  than  the  actual  packet  length  pass  the  parity  check 
and  are  accepted  as  valid  by  the  microcode.  In  such  cases, 
the  microcode  will  not  generate  a  satellite  input  complete 
interrupt  until  the  number  of  bits  corresponding  to  the 
corrupted  packet  length  has  been  received. 

3.  With  a  lightly  loaded  channel,  a  period  of  10  seconds  is 
insufficient  for  the  Black  processor  to  clock  enough  bits 
through  the  crypto  corresponding  to  the  corrupted  packet 
length . 
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4.  When  no  satellite  input  complete  interrupt  occurs  during  a 
10-second  interval,  the  Satellite  IMP  macrocode  resets  the 
satellite  channel  interface  and  declares  a  loss  of  frame 
synchronization  (the  inability  of  a  Satellite  IMP  to  hear 
even  a  single  one  of  its  own  hello  packets  during  this 
length  of  time  indicates  a  severe  problem  somewhere  in  the 
channel ) . 

The  plausibility  of  this  sequence  of  events  is 
experimentally  confirmed  by  several  pieces  of  evidence.  First, 
in  Experiment  #2,  multi-block  packets  were  accepted  as  valid  by 
the  Black  processor  even  though  only  single-block  packets  were 
transmitted;  in  Experiment  #1  ,  this  discrepancy  never  occurred. 
The  improper  decoding  of  the  number  of  blocks  in  a  packet  is 
undesirable,  since  the  satellite  channel  will  be  blocked  by  the 
Black  processor  for  an  interval  corresponding  to  the  size  of  the 
improperly  decoded  packet-length  value,  during  which  time  packets 
are  lost.  Second,  the  value  in  the  FALSE-SYN  counter  that  is 
kept  by  the  Satellite  IMP  was  46  times  higher  in  Experiment  #2 
than  in  Experiment  #1.  (Whenever  the  microcode  finds  a  SYN 
character  in  the  satellite  input  bit  stream,  while  the  subsequent 
packet  length  value  is  rejected  due  to  a  parity  check  error,  the 
FALSE-SYN  counter  is  incremented,  and  the  microcode  begins 
hunting  for  another  SYN  character.)  Although  FALSE-SYNs  represent 
packet  lengths  that  were  rejected  and  therefore  do  not  block  the 
satellite  input,  the  large  increase  in  the  FALSE-SYN  count 
indicates  a  greater  likelihood  of  a  corrupted  packet  length  being 
accepted.  Note,  the  error  detecting  code  that  is  used  for  the 
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packet  length  field  will  detect  all  1-bit  and  2-bit  errors. 
However,  in  the  case  of  random  data  being  sent  to  the  Satellite 
IMP,  the  probability  .that  a  packet  length  value  passes  the 
validity  test  is  1/16. 

In  Experiment  #3  (contention,  experimental  control),  the 
experimental  configuration  was  identical  to  Experiment  #2  with 
the  exception  that  the  Satellite  IMPs  were  connected  through  the 
digital  satellite  channel  simulator  instead  of  over  the  FLTSATCOM 
satellite  channel.  Stable  network  operation  was  verified  for  a 
period  of  one  hour,  confirming  the  ability  of  the  Satellite  IMPs 
to  maintain  synchronization  while  contention  packets  are 
discarded . 

The  results  from  these  experiments  unambiguously  indicate 
that  the  current  implementations  of  the  MATNET  Red  and  Black 
subsystems  cannot  provide  reasonable  system  performance  when 
contention  packets  occur  on  the  satellite  channel.  Network 
performance  is  so  severely  degraded,  apparently  due  to  the 
inability  of  the  system  to  correctly  determine  packet  boundaries 
of  contention  packets,  that  synchronization  of  all  sites  cannot 
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Note  that  outside  interference  has  been  observed  many  times 
during  the  January  MATNET  tests  (because  the  interference 
repeatedly  occurred  on  the  hour,  we  can  conclude  that  its  cause 
is  external  to  our  system).  Such  interference  often  affects 
experiments  that  are  in  progress. 
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